home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000033_owner-urn-ietf _Thu Jan 30 18:34:11 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA19805 for urn-ietf-out; Thu, 30 Jan 1997 18:34:11 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA19788 for <urn-ietf@services.bunyip.com>; Thu, 30 Jan 1997 18:34:08 -0500
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA18586  (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 18:34:02 -0500
  5. Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id QAA15556; Thu, 30 Jan 1997 16:33:42 -0700 (MST)
  6. Message-Id: <199701302333.QAA15556@acl.lanl.gov>
  7. From: "Ron Daniel Jr." <rdaniel@lanl.gov>
  8. To: "Ian Higgs +44 171 542 8595" <IAN.HIGGS@reuters.com>
  9. Cc: "URN Mailing list" <urn-ietf@bunyip.com>
  10. Subject: Re: [URN] Fragment references.
  11. Date: Thu, 30 Jan 1997 16:22:59 -0700
  12. X-Msmail-Priority: Normal
  13. X-Priority: 3
  14. X-Mailer: Microsoft Internet Mail 4.70.1155
  15. Mime-Version: 1.0
  16. Content-Type: text/plain; charset=ISO-8859-1
  17. Content-Transfer-Encoding: 7bit
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: "Ron Daniel Jr." <rdaniel@lanl.gov>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Thus spoke Ian Higgs
  24.  
  25. > Has everybody already agreed that a URN is NOT a form of URI
  26. > and the "/" character does NOT imply a hierarchy as stated in RFC1630?
  27.  
  28. No. That is pretty much the discussion we are having now.
  29.  
  30. My current position is that:
  31.  1  URNs are one of the two forms of URI.
  32.  2  URLs are the other form of URI.
  33.  3  URNs are not URLs although they have a similar syntax. In fact,
  34.     we purposefully try to align our syntax with that of URLs in order
  35.     to avoid gratuitous differences. However, we don't adopt all of the
  36.     URL syntax features until we see how they impact the core purpose of
  37.     URNs - persistent, location-independent, resource identifiers.
  38.         (The difference, to me, is that URNs MUST NOT specify any
  39.          resolution-system specific hints, like protocol, port, host, etc.
  40.          while URLs typically do specify such things.)
  41.         (As a side note, the question of whether there really is a
  42.          difference between URNs and URLs has been beaten to death and has
  43.          been declared out of bounds for this list. The URN-WG charter
  44.          assumes there is such a difference, and if there is not then the
  45.          worst that happens to the world is that our work is moot.)
  46.  4  In the absence of good arguments to the contrary, unencoded '/' in URNs
  47.     will end up denoting hierarchy as stated in RFC 1630.
  48.  5  Since we have only just started seriously discussing relative URNs,
  49.     we have not reached consensus on the existance or absence of such a
  50.     good argument.
  51.  6  Since the URN-WG is chartered to produce a URN Syntax draft, and
  52.     neither the charter or URN requirements RFC mentions relative URNs, we
  53.     should not stop the syntax draft while we discuss them.
  54.  7  Therefore, the syntax draft should leave an escape hatch for relative
  55.     URNs.
  56.  8  This is easy to do, we just state that '/' SHOULD (not MUST) be
  57.     %encoded, leaving the door open for people not to encode it if they
  58.     think
  59.       a) they are following the letter and spirit of 1630
  60.       b) whatever we do decide will be in line with 1630
  61.  
  62. > I think that I missed that.
  63. > If so then there can be no such thing as relative URNs and all URNs
  64. > might as well be 32 digit random numbers (for which there IS a case).
  65.  
  66. One of the URN requirements is to accomodate legacy namespaces. ISBN,
  67. UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify
  68. important content. Further, they are easy to map to the URN Syntax draft
  69. as it currently exists. There is no need to say all URNs must be 32digit
  70. random numbers. Such a namespace canbe created if you want, but there is
  71. no reason to preclude the ones I cite above.
  72.